PR build and push workflows (test + benchmark)#10
PR build and push workflows (test + benchmark)#10pnivlek wants to merge 1 commit intoOpenSource-Deadlock-Tools:mainfrom
Conversation
Makes a pr build workflow to build and test the code on every PR or push.
|
Sorry for the late reply, never got a notification. I would love to have a better CI/CD to give a baseline of releases as I think it's core to making sure the code remains high quality. However, I am less experienced with GH actions compared to other run server solutions, so I am going to do some research to make sure there won't be any weird pricing concerns if I set this to auto run. Might be a prereq to setup a release tagging procedure to run benchmarks against as I did not put a lot of consideration into the branch layout I want to use yet (although feature and pending release branches is likely what I will go with) |
|
No worries! I purposely didn't remind you of it earlier because it's not really blocking anything else. I have also not used actions outside of like, one or two personal repos that would never hit any paid limits. From what I can tell, we would get 2000 minutes of runtime per month across the organization. The whole workflow currently takes around 2m25s to run so it should be a while before it runs out at our current rate (800 PRs/pushes to main). Although, as we add the ui/core/stats repositories, we should probably only run benchmarks on tagged commits/commits with a keyword in them. As far as charging goes, it sounds like we won't be charged and it should cut us off if we hit the limit, but you should definitely double check. |
This makes a pr build workflow to build and test the code on every PR or push. This is a slight no-op since there's no testing, but I figure it's worth adding anyways since the benchmark also acts as an integration test.
A future improvement would be to actually leave a comment when the benchmark gets 100%(?) worse in a PR, but for now it just runs one.
I've tested the github actions code by pushing to a private hard fork, since forks don't run actions normally.